\chapter{Architectuur}
\label{Architectuur}

Om least-privilege integration van componenten aan te bieden, zonder de gekende nadelen (e.g. client-side aanpassingen), stellen
we een nieuwe client-side beveiligingsarchitectuur voor die ge\"inspireerd is door Webjail \cite{webjail}.
Deze architectuur moet  het mogelijk maken voor de integrator om individuele componenten in een mashup te integreren volgens het least-privilege principe.
In deze opstelling moet de integrator de mogelijkheid hebben een security policy te laten defini\"eren per component, die afgedwongen zal worden in de browser.

Deze security policy defini\"eert de set van gevoelige JavaScript operaties die beschikbaar zijn voor de component.
Elke operatie kan expliciet worden toegestaan voor elke component volgens een zelf-gedefini\"eerde whitelist in de policy.

In deze sectie wordt beschreven hoe deze architectuur kan werken. 
We zullen onder andere onze keuzes motiveren en kijken of de doelstellingen daarmee behaald kunnen worden.

\section{Werking}
De bedoeling is dat de externe component niet meer rechtstreeks de gevoelige JavaScript operaties kan uitvoeren.
Alle communicatie tussen externe component en browser zal worden gedelegeerd door een tussenpersoon.
Deze tussenpersoon beslist welke operaties de externe component mag uitvoeren en welke niet.
Enkel de operaties die toegelaten zijn, zal de tussenpersoon dan doordelegeren naar de browser.\emph{(D1: Afschermen van functies)}

Onder communicatie verstaan we JavaScript calls, dus onze tussenpersoon moet JavaScript verstaan. 
Daarom maken we gebruik van een JavaScript interpreter, deze verstaat JavaScript en kan onmiddellijk zelf de nodige JavaScript calls doen in de browser.

	\begin{figure}[h]
		\centering
 		\includegraphics[width=0.80\textwidth]{img/codeflowSD.png}
 		\caption{Code flow externe component}
 		\label{CodeFlow}
	\end{figure}

In plaats van de externe component in te laden via de script tag als bij script inclusion, zal de integrator de code rechtstreeks in deze interpreter laden.
De code van de component, gegeven als string, wordt door deze dan ge\"evalueerd en ge\"interpreteerd. Net zoals dit anders door de interpreter in de browser zou gebeuren.
Hierdoor weet de interpreter welke operaties er moeten uitgevoerd worden. Voor elk van deze operaties gaat de interpreter nu checken in de policy, welke operatie er uitgevoerd moet worden.
Deze policy is vooraf gegenereerd en zal de advised operatie terug geven. Indien de operatie is toegelaten, is dit dezelfde operatie, in het andere geval kan er bijvoorbeeld een functie teruggegeven worden die niets doet.
Daarna kan de interpreter de advised operatie gewoon uitvoeren in de browser.

Deze architectuur is gebaseerd op de deep advice aanpak van Conscript\cite{conscript} (en Webjail \cite{webjail}), het grote voordeel is dat we hier geen aanpassing meer nodig hebben aan de browser.
We vervangen dit door de JavaScript interpreter in de vorm van JavaScript code mee te sturen van de server naar de client. \emph{(D4: Geen client-side aanpassingen)}

We kiezen ook voor een JavaScript interpreter omdat er zo geen code moet herschreven worden. Daarbij moeten we ook geen beperkingen op de code leggen.
De code wordt ge\"interpreteerd, net zoals het in de browser het geval zou zijn. \emph{(D2: Geen aanpassingen aan code)}

\section{Client-side JavaScript interpreter}

De externe componenten zullen dus uitgevoerd worden aan de client-side in een JavaScript interpreter dat zo aangepast is dat deze de security policies kan afdwingen.
Zoals vermeld in sectie \ref{browserupdAdv}, kunnen we geen gebruik maken van de JavaScript interpreter die ingebouwd is in de browser.
Er is nood aan een oplossing die werkt onafhankelijk de versie van de browser.
Onze architectuur stelt voor een interpreter mee in de mashup pagina in te laden, die op zijn beurt kan uitgevoerd worden in de browser.
In de browseromgeving is er standaard slechts een programmeertaal beschikbaar, JavaScript. Dit wil zeggen dat we gebruik zullen moeten maken van een JavaScript interpreter die zelf in JavaScript geschreven is. \footnote[1]{Deze zou eventueel ook in Java of ActionScript geschreven kunnen worden, maar aangezien deze niet standaard zijn is het mogelijk dat de client eerst een browser plugin zou moeten installeren}
Zoiets wordt ook een meta-circular interpreter genoemd.

Er bestaat al een meta-circular interpreter voor JavaScript, Narcissus genaamd.
Ook al is Narcissus $"$maar$"$ een research project, toch zullen we ervan gebruik maken in ons prototype.
Voor deze thesis proberen we aan te tonen dat het mogelijk is met deze architectuur de noden te vervullen, als een proof-of-concept.
De werking van Narcissus zelf zal verder besproken worden in het volgende hoofdstuk. Verder zal tijdens de bespreking van de implementatie (hoofdstuk \ref{ImplementatiePrototype}) besproken worden welke aanpassingen er daarvoor moesten doorgevoerd worden in Narcissus.

\subsection{Interpreter context}

Een belangrijke concept bij het gebruik van zo'n client-side interpreter is de context waarin de code uitgevoerd wordt.
Eerst is er de \emph{browser context}, dit is de context van de ingebouwde JavaScript interpreter van de browser. In deze context wordt standaard JavaScript code uitgevoerd,
de client-side interpreter zal eveneens in deze context uitgevoerd worden.
Dan is er de \emph{interpreter context}, dit is de context van de client-side interpreter. In deze context zullen de externe componenten uitgevoerd worden.

Deze contexten fungeren als een soort van sandboxen,
zo krijgt de code die uitgevoerd wordt in de interpreter context geen toegang tot de variabelen en functies die gedeclareerd zijn in de browser context.

De security policies zullen dan ook enkel van toepassing zijn op de code die uitgevoerd wordt binnen de interpreter context. 
Het moet dan onmogelijk zijn voor code die uitgevoerd wordt in de interpreter context, om uit zijn context te breken en zo code te laten uitvoeren in de context van de browser.
Deze laatste uitdrukking is niet makkelijk te bereiken in de complexe browser omgeving en zal verder besproken worden in sectie beveiliging tijdens de evaluatie (hoofdstuk \ref{Evaluatie}).

\section{Security policy}

De security policy is gebaseerd op deze van Webjail \cite{webjail}, ze defini\"eert een set van gevoelige JavaScript operaties die toegelaten zijn.
Elke operatie kan worden toegestaan of afgedwongen voor elke component volgens een zelf gedefini\"eerde whitelist.
Alle gevoelige operaties die niet expliciet worden toegestaan in de beschreven policy, zullen geblokkeerd worden wanneer de mashup deze probeert op te roepen.\emph{(D3: Security Policy)}

De policies zijn van toepassing op de code die wordt uitgevoerd in de client-side interpreter. Per stuk code dat apart wordt uitgevoerd kan er een nieuwe 
policy worden toegepast. In de context van deze thesis komt het erop neer dat elke component zijn eigen policy kan krijgen.

\subsection{Formaat policies}

De policies worden gedeclareerd in JavaScipt Object Notation (JSON), dit is een eenvoudig formaat dat in JavaScript automatisch omgezet wordt in objecten.
Elke policy is een whitelist van alle groepen gevoelige operaties die kunnen toegestaan worden, elke groep die niet voorkomt in de policy wordt automatisch geblokkeerd, maar deze kunnen ook nog expliciet geweigerd worden.
Een lege policy is dus een policy dat geen enkel gevoelige operatie toestaat.

\begin{lstlisting}[caption=Voorbeeld van een policy.]
 { 'cookie-read' : 'yes',
   'cookie-write' : 'yes',
   'extcomm' : 'yes',
   'geolocation' : 'no' }
\end{lstlisting}

De gevoelige JavaScript operaties uit de HTML5 APIs zijn verdeeld in negen groepen volgens hun functionaliteit: DOM toegang, cookies, externe communicatie,
inter-frame communicatie, client-side opslag, UI, media, geolocatie, en toegang tot devices. De indeling van de operaties is te zien in tabel \ref{indeling_operaties}.

\begin{table}[ht]
\centering
\begin{tabular}{l l}
\hline
Groep           & Operaties \\
\hline
domaccess-read  & DOM lees operaties. \\
		& Bv: \lstinline|document.getElementById()|, etc. \\
domaccess-write & DOM schrijf operaties. \\
		& Bv: \lstinline|document.write()|,  etc. \\
cookies-read    & Cookie lees rechten. \\
cookies-write   & Cookie schrijf rechten. \\
extcomm         & Externe communicatie. \\
		& Bv: \lstinline|XMLHttpRequest|, \lstinline|WebSocket|, etc. \\
framecomm       & Inter frame communicate. \\
		& Bv: \lstinline|window.postMessage()|, \lstinline|window.onmessage|. \\
storage-read    & Storage read access. \\
		& Bv: \lstinline|window.localStorage.setItem()|, FileAPI, etc.\\
storage-write   & Storage write access. \\
		& Bv: \lstinline|window.localStorage.getItem()|, FileAPI, etc. \\
ui              & History API en drag and drop events. \\
media           & Media capture API\\
geolocation     & Geolocation access. \\
		& Bv: \lstinline|navigator.geolocation.getCurrentPosition()|, etc. \\
device          & Device access. \\	
\hline
Aantal gevoelige operaties: 86 \\
\hline\end{tabular}
\caption{Indeling gevoelige operaties.}\label{indeling_operaties}
\end{table}

\section{Conclusie}
Alle vier de doelstellingen worden met deze architectuur voldaan. De JavaScript interpreter zal er voor zorgen dat alle paden naar eenzelfde object, op dezelfde manier behandeld kunnen worden.
Zoals dit in doelstelling D1 was opgesteld. De JavaScript interpreter maakt het ook mogelijk dat aan doelstelling D2 voldaan kan worden.
Het idee dat we de interpreter van de server kant pushen naar de client kant, zorgt er voor dat er geen aanpassingen gedaan moeten worden aan de browser. Zo is ook aan doelstelling D4 voldaan.
Als laatste hebben we de policy taal beschreven, die binnen onze architectuur past. Deze zorgt dat ook aan de overblijvende doelstelling D3 voldaan wordt.

